<HTML><HEAD><TITLE>lp_demon_setup(+Objective, ?Cost, ++ListOfOptions, ++TriggerModes, -Handle)</TITLE>
</HEAD><BODY>[ <A HREF="index.html">library(eplex)</A> | <A HREF="../../index.html">Reference Manual</A> | <A HREF="../../fullindex.html">Alphabetic Index</A> ]
<H1>lp_demon_setup(+Objective, ?Cost, ++ListOfOptions, ++TriggerModes, -Handle)</H1>
Setup the external solver as a simplex demon.
<DL>
<DT><EM>Objective</EM></DT>
<DD>Objective function: min(CostExpr) or max(CostExpr)
</DD>
<DT><EM>Cost</EM></DT>
<DD>Variable bounded by the optimal solution
</DD>
<DT><EM>ListOfOptions</EM></DT>
<DD>List of solver options
</DD>
<DT><EM>TriggerModes</EM></DT>
<DD>List of conditions for re-triggering solver
</DD>
<DT><EM>Handle</EM></DT>
<DD>handle to solver state
</DD>
</DL>
<H2>Description</H2>
<P>
  Setup the external solver as a simplex demon. A simplex demon collects
  linear constraints and re-solves the problem whenever the triggering
  conditions in TriggerModes are met.

</P><P>
  Declaratively, this can be seen as a compound constraint representing all
  the individual linear constraints that have been set so far and are going
  to be set up later.  Operationally, the delayed constraints are collected
  and an external solver is set up (as with lp_setup/4).  Then the problem
  is solved once initially (if <TT>initial_solve</TT> option is yes) and a
  delayed goal lp_demon is set up which will re-trigger the solver when 
  certain  conditions are met.

</P><P>
  <TT>CostExpr</TT> is a linear cost expression (or quadratic, if supported
  by the external solver).

</P><P>
  <TT>Handle</TT> refers to the created solver state (as in lp_setup/4 or
  lp_read/3 described below). It can be used to access and modify the state
  of the solver, retrieve solution information etc. 

</P><P>
  Unlike with lp_solve/2, <TT>Cost</TT> will not be instantiated to a
  solution's cost, but only be bounded by the best-bound on cost:
  For a minimisation problem, each solution's best-bound becomes a lower bound,
  for maximisation an upper bound on Cost.  This technique allows for
  repeated re-solving with reduced bounds or added constraints. Note that
  Cost is not automatically made a problem variable (it can be a problem
  variable if there are constraints that involve it), and thus may not have
  bounds associated with in. In order for the bounds information not to be
  lost, some bounds should be given to <TT>Cost</TT> (e.g. making it a
  problem variable (but this might introduce unnecessary self-waking on
  bounds change), or via another solver with bounds (e.g. ic)).
</P><P>
  <TT>ListOfOptions</TT> is a list of solver options as described for
  lp_setup/4. In addition, the following extra options are also available:
   
<DL>

<DT><STRONG><TT>collect_from(+Pool)</TT></STRONG>
    <DD>Specifies if this solver state should be associated with an eplex
    instance. If Pool is <TT>none</TT>, then the solver is not associated
    with an eplex instance. If Pool is <TT>pool(Instance)</TT>, where
    Instance is the (atomic) name of an existing eplex instance, then this
    eplex instance would be associated with the solver state, i.e. when the
    solver is invoked, it will collect constraints posted to
    <TT>Instance</TT>.  Note that <TT>Instance</TT> must not be associated
    with any other solver state already.
</P><P>
    The default value for <TT>Pool</TT> is pool(eplex) (for backward
    compatibility).

<P>
<DT><STRONG><TT>initial_solve(+YesNo)</TT></STRONG>
    <DD>Specifies if an initial solve (call to the external solver) should
    be performed immediately after problem setup.
    YesNo is one of the atoms <TT>yes</TT> or <TT>no</TT>, the default is 
    <TT>yes</TT> if any trigger condition is specified in TriggerModes, 
    <TT>no</TT> if no trigger condition is specified.
</DL>
   
</P><P>

  <TT>TriggerModes</TT> specifies under which conditions the solver demon
  will be re-triggered. It can be a list of the following specifiers

<DL>

  <DT><STRONG><TT>inst</TT></STRONG>
  <DD>re-trigger if a problem variable gets instantiated.

  <DT><STRONG><TT>ModuleName:Index</TT></STRONG>
  <DD>re-trigger when the  suspension list given by ModuleName:Index is woken
  for any of the problem variables.
  The format for <TT>ModuleName:Index</TT> is the same as for specifying
  the suspension list in suspend/3,4.

  <DT><STRONG><TT>deviating_inst</TT></STRONG>
  <DD>re-trigger if a problem variable gets instantiated
      to a value that differs from its lp-solution more than a tolerance.

  <DT><STRONG><TT>bounds</TT></STRONG>
  <DD>re-trigger each time a variable bound for the solver instance changes.

  <DT><STRONG><TT>deviating_bounds</TT></STRONG>
  <DD>re-trigger each time a variable's solver instance bound changes
      such that its lp-solution gets excluded more than a tolerance.

  <DT><STRONG><TT>new_constraint</TT></STRONG>
  <DD>re-trigger each time a new (arithmetic or integral) constraint is
      added to the solver instance. Note that adding integral constraint
      on new problem variables, or adding bounds constraint, or adding 
      constraints to the cutpool will *not* re-trigger.

  <DT><STRONG><TT>trigger(Atom)</TT></STRONG>
  <DD>re-trigger each time the symbolic trigger Atom is pulled by invoking 
      schedule_suspensions/1

  <DT><STRONG><TT>pre(Goal)</TT></STRONG>
  <DD>an additional condition to be used together with other triggers. When 
      the demon is triggered, it first executes <TT>PreGoal</TT>. Only if 
      that succeeds, does the appropriate external solver get invoked.
      This provides a way of reducing the number of (possibly expensive)
      solver invocations when given preconditions are not met.

  <DT><STRONG><TT>post(Goal)</TT></STRONG>
  <DD>this is not a trigger condition, but specifies a goal to be executed
      after solver success, but before the Cost variable gets
      constrained. It is intended as a hook for exporting solution
      information, e.g. copying solutions from the solver state into
      variable attributes (eg. tentative value), or computing weights for
      labelling heuristics from the solver state.  
  <DT><STRONG><TT>suspension(Susp)</TT></STRONG>
  <DD>this is not a trigger condition, but instead is used to access the 
      demon used to trigger the solver. Susp is instantiated to
      the suspension that triggers the solver: by waking Susp, the solver
      is triggered. Susp is a demon in that it stays around after being
      woken. Accessing Susp allows the user to specify orbitally conditions 
      for triggering the solver.
</DL>

  The tolerances mentioned can be specified in lp_setup/4 or lp_set/3
  as <TT>demon_tolerance</TT>.

</P><P>
  If several trigger conditions are specified, then any of them will trigger
  the solver.

</P><P>
  When a solver demon runs frequently on relatively small problems,
  it can be important for efficiency to switch off the presolve option
  to reduce overheads.

</P><P>
  The solver demon calls lp_solve/2 when it wakes up. See the description
  of lp_solve/2 for the handling of exceptions.
</P><P>
  Note: Some external solvers need to write temporary files when they
  are solving a problem. These are written to the temporary directory
  specified in ECLiPSe's tmp_dir setting (get_flag/2, set_flag/2).
</P>
<H2>Examples</H2>
<PRE>   Some common invocations patterns for this predicate are the following.
   The first triggers the solver only on instantiation of variables to
   values that don't fit with the simplex solution:

      lp_demon_setup(min(Expr), C, [], [deviating_inst], H)

</PRE>
<H2>See Also</H2>
<A HREF="../../lib/eplex/lp_solve-2.html">lp_solve / 2</A>, <A HREF="../../lib/eplex/lp_set-3.html">lp_set / 3</A>, <A HREF="../../lib/eplex/lp_setup-4.html">lp_setup / 4</A>, <A HREF="../../lib/eplex/lp_get_iis-5.html">lp_get_iis / 5</A>, <A HREF="../../lib/eplex/solution_out_of_range-1.html">solution_out_of_range / 1</A>, <A HREF="../../kernel/suspensions/schedule_suspensions-1.html">schedule_suspensions / 1</A>, <A HREF="../../lib/constraint_pools/index.html">library(constraint_pools)</A>
</BODY></HTML>
